You were expecting easy to follow documentation? Too bad! It's train-of-thought
time! -cjb


> Requirements

The development systems are ARM and Intel Devuan Linux boxen. NetBSD had
issues with Direwolf, but it should work with a TNC.

INN
- I'm using 1.7.2q; a INN-2.x test install wasn't too difficult.
- needs the traditional directory-based news spool with one post per file.

Python 2.7 ("ANSI Python")
...so people with an invested interest and their parrots say it's depreciated,
but it's winning from not being a constantly breaking target where large
projects need crocks like Containers because of cascading dependencies each
having a new API every other week. I also hate the "print ()" change.


> Site configuration

There's 3 subsystems:

    1 * The News Server

    . basic installation of a plain newsserver
    . adding _scrub to /etc/news/newsfeeds to sanatize the postings

It should be doable to run Usenet newsgroups and QRPBBB newsgroups on the same
newsserver, managing traffic with the distribution mechanism-- but that's not
quite there yet. "Best practice" would still be to have a seperate server.
Still, being a newsserver allows additional options like distributing QRPBBB
messages via NNTP or UUCP (over your Radio TCP network of course), and using
newfangled GUI newsreaders from another computer on a LAN.

    2 * The Radio and TNC

After dealing with the radio hardware that gets an RF signal to the desk, this
subsystem involves the creation of /var/spool/packet/{recv,send} for a kissutil
(or similar) process(es). Boot.sh is involved with this.

    3 * Message Transfer Processing

Obviously site-config.py .. TXSLOT should be different for all stations in your area.

The qrpbbb_* scripts .. These should be usable either from the command-line, or
executed via cron-- not much testing on the second yet. Look at Run.sh for ideas.


> Newsserver configuration

distrib.pats
    Along the lines of:

    5:radio.*:radio
    1:*:qrpbbb

newsfeeds

    ME:*,!control,!junk,!local.*/!local::
    scrub:*/!*,qrpbbb,radio,fastradio:Tc,Wf:/root/qrpbbb/qrpbbb_scrub.py

Make sure the script and its associated files are accessible to the news user.

active
    To get you started..

    newgroup qrpbbb.general y
             qrpbbb.control m
             qrpbbb.announce m
             <your callsign>.general y

    There'll be occasional checkgroups postings... Or ask through email.

The remaining configuration files are your problem. You'll of course verify the
newsserver starts up and posting works as it should.


> A QRPBBB user's average day on the network...

<get your radio hardware set up, frequencies set, site_config.py edited>
   $ qrpbbb_schedule.py   # start the daemon for moving packets to the TNC

..this doesn't exit, so in another terminal:

   $ qrpbbb_beacon.py     # announce that you're online
   $ qrpbbb_ihave.py      # broadcast all your known messages

1: $ qrpbbb_process.py    # deal with any packets in the spool
   $ qrpbbb_queuecheck.py # clean up/post any old/new messages
   $ qrpbbb_ihave.py 3    # broadcast any recent messages you've got
   $ qrpbbb_iwant.py	  # broadcast what you're missing
   $ sleep 600
   $ goto 1:

(Or, just a ./Run.sh. Creating cronjobs would be even less work.)

While that's running, switch over to your newsreader and enjoy.


> Cron

Automatic operation has not had much attention as yet, but for the meantime,
an example crontab for the user hosting QRPBBB might look like:

    0     21,0,3,6,12,18 * * * /root/qrpbbb/qrpbbb_beacon.py >/dev/null
    #10   21,0,3,6  * * * /root/qrpbbb/cron_ihave.sh
    #40   21,0,3,6  * * * /root/qrpbbb/cron_iwant.sh

    *     21-23,0-5 * * * /root/qrpbbb/cron_schedule.sh
    */2   6-20      * * * /root/qrpbbb/cron_schedule.sh

    */5   *         * * * /root/qrpbbb/cron_process.sh

No, it doesn't really have to run as root.

12 hour turn-around on message replies builds character. Seriously.
(Australia's early Usenet had ~2 week turn-around and involved magtapes being
mailed overseas..)

The APRS network's 'peak' usage within the 2-digi region of Sydney is between
9am-6pm with 160-200 packets per hour, with off-peak traffic being half that.
I'm thinking while there's still only a few stations, a tx frequency of every
2 minutes during peak times should not have a noticeable impact on the APRS
network-- but we'll see.
